OpenCores
no use no use 1/1 no use no use
CRC-32 Calculation for non-aligned packets
by Unknown on Mar 2, 2004
Not available!
Hi,

I'm in the process of writing a HDLC mapper and I looked into the mailing
list and found the discussion attached below.

My question is, if you do not know what length the packet is in advance, how
do you solve the initialization problem ? I do not wish to buffer the entire
packet before I can calculate the CRC on it.

Is there a solution to that, or am I completly on the wrong track ?

Thanks,
Erez.

Attached msg below:


Mathew Hi,

The idea behind unaligned width is that indeed as you understood we
pad with "enough" "same pattern" to fill and align the width.

now that we have the padding you data is align so this part is solved.

the problem you need now to solve is that you don;t really want to calculate
the crc of the padding as this is just for alignment purpose.

and so the solution is that you do "back calculation" of the crc and find
the initial crc value that once tha padding pass through it you get all "1"
and so your crc machine caluclate in reality only the data.

this way you get calculation of only the real data as well as your data is
align.

I'm off for almost 4 weeks, so if you have more question I'm sure other can
also help and if not once I'm back I will try to answer what still is not
clear.

good luck and have fun with your crc machines.

Illan

CRC-32 Calculation for non-aligned packets
by Unknown on Mar 12, 2004
Not available!
Erez Hi, The simplest solution if you know nothing about what will be, is to work in byte width than there is no need to pad or know anything in advance. if you desire to work in wider bus than what you really need to know is not the length but rather the modolo of the length so for example if you are working in word (32 bit) packet with 65 byte of data (data that need to have crc calculted on) all that intrest you is that this is 1 byte out of the 4 byte in a word. so in this case what you need to know is that 65%4=1 and so 69 which have the same modolo result will be treated the same. this might be of no help if you have no way to know the modolo and need to calculate first the length. you might want to see if you can add padding and thus align your packet to be always word (assume you use word), and thus no need to pre condifgure the crc init value. you can also consider increase the speed of the crc machine and thus get it work effectivly in byte width, but this depend mainly on the speed you already runing and the device (fpga/asic) you are using. have a nice day Illan -----Original Message----- From: Erez Birenzwig [mailto:erez_birenzwig@yahoo.com] Sent: Monday, March 01, 2004 6:29 PM To: ethmac@opencores.org Subject: [ethmac] CRC-32 Calculation for non-aligned packets Hi, I'm in the process of writing a HDLC mapper and I looked into the mailing list and found the discussion attached below. My question is, if you do not know what length the packet is in advance, how do you solve the initialization problem ? I do not wish to buffer the entire packet before I can calculate the CRC on it. Is there a solution to that, or am I completly on the wrong track ? Thanks, Erez. Attached msg below: Mathew Hi, The idea behind unaligned width is that indeed as you understood we pad with "enough" "same pattern" to fill and align the width. now that we have the padding you data is align so this part is solved. the problem you need now to solve is that you don;t really want to calculate the crc of the padding as this is just for alignment purpose. and so the solution is that you do "back calculation" of the crc and find the initial crc value that once tha padding pass through it you get all "1" and so your crc machine caluclate in reality only the data. this way you get calculation of only the real data as well as your data is align. I'm off for almost 4 weeks, so if you have more question I'm sure other can also help and if not once I'm back I will try to answer what still is not clear. good luck and have fun with your crc machines. Illan _______________________________________________ http://www.opencores.org/mailman/listinfo/ethmac
CRC-32 Calculation for non-aligned packets
by Unknown on Mar 12, 2004
Not available!
Hi Ilan, Thanks for that. Unfortunatly I'm working in an FPGA so no luck with speed increase. I'm doing the RX path so there's no way of knowing in advance what the length of the packet will be as I do the processing on the fly. From looking around a bit I see there are two practical ways of doing the CRC calculation, and I chose the one that requires me to have four CRC calculators one for each width. This one also scales well for higher frequencies if required (Lots of gates though, but I guess oyu have to pay somewhere...) Thanks a gain, Erez. --- Illan Glasner IGlasner@mrv.com> wrote:
Erez Hi, The simplest solution if you know nothing about what will be, is to work in byte width than there is no need to pad or know anything in advance. if you desire to work in wider bus than what you really need to know is not the length but rather the modolo of the length so for example if you are working in word (32 bit) packet with 65 byte of data (data that need to have crc calculted on) all that intrest you is that this is 1 byte out of the 4 byte in a word. so in this case what you need to know is that 65%4=1 and so 69 which have the same modolo result will be treated the same. this might be of no help if you have no way to know the modolo and need to calculate first the length. you might want to see if you can add padding and thus align your packet to be always word (assume you use word), and thus no need to pre condifgure the crc init value. you can also consider increase the speed of the crc machine and thus get it work effectivly in byte width, but this depend mainly on the speed you already runing and the device (fpga/asic) you are using. have a nice day Illan -----Original Message----- From: Erez Birenzwig [mailto:erez_birenzwig@yahoo.com] Sent: Monday, March 01, 2004 6:29 PM To: ethmac@opencores.org Subject: [ethmac] CRC-32 Calculation for non-aligned packets Hi, I'm in the process of writing a HDLC mapper and I looked into the mailing list and found the discussion attached below. My question is, if you do not know what length the packet is in advance, how do you solve the initialization problem ? I do not wish to buffer the entire packet before I can calculate the CRC on it. Is there a solution to that, or am I completly on the wrong track ? Thanks, Erez. Attached msg below: Mathew Hi, The idea behind unaligned width is that indeed as you understood we pad with "enough" "same pattern" to fill and align the width. now that we have the padding you data is align so this part is solved. the problem you need now to solve is that you don;t really want to calculate the crc of the padding as this is just for alignment purpose. and so the solution is that you do "back calculation" of the crc and find the initial crc value that once tha padding pass through it you get all "1" and so your crc machine caluclate in reality only the data. this way you get calculation of only the real data as well as your data is align. I'm off for almost 4 weeks, so if you have more question I'm sure other can also help and if not once I'm back I will try to answer what still is not clear. good luck and have fun with your crc machines. Illan _______________________________________________ http://www.opencores.org/mailman/listinfo/ethmac _______________________________________________ http://www.opencores.org/mailman/listinfo/ethmac



no use no use 1/1 no use no use
© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.